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Abstract. Interactive systems with registers and voices (shortly, rv- 
systems) are a model for interactive computing obtained closing register 
machines with respect to a space-time duality transformation ("voices" 
are the time-dual counterparts of "registers"). In the same vain, AGAPIA 
vO.l, a structured programming language for rv-systems, is the space- 
time dual closure of classical while programs (over a specific type of 
data). Typical AGAPIA programs describe open processes located at 
various sites and having their temporal windows of adequate reaction 
to the environment. The language naturally supports process migration, 
structured interaction, and deployment of components on heterogeneous 
machines. 

In this paper a sound Hoare-like spatio-temporal logic for the verifica- 
tion of AGAPIA vO.l programs is introduced. As a case study, a formal 
verification proof of a popular distributed termination detection protocol 
is presented. 



1 Introduction 

Verification, a pillar of the development of reliable software, is notoriously diffi- 
cult. Full verification was a never reach goal even for sequential programs. (How- 
ever, currently Floyd-Hoare verification style regains popularity, being part of 
modern programming development platforms where users interactively develop 
and verify complex software systems.) For concurrent, parallel, or distributed 
programs, where the tasks are much more complex, the approach was partially 
replaced by lighter verification methods (for instance model-checking, run-time 
verification, testing, etc.), where specific system properties are verified. The 
downside of these propriety-based verification methods is the partial coverage of 
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systems, cither due to theoretical hmitations of the methods themselves or due to 
practical consideration (as the proprietary rights of certain running platforms). 

Interactive computing [14]^ is a step forward on system modularization. The 
approach allows to describe parts of the systems and verify them in an open en- 
vironment. A model for interactive computing systems (consisting of interactive 
systems with registers and voices - rv-systems) and a core programming language 
(for developing rv-programs) have been proposed in [26] based on register ma- 
chines and a space-time duality transformation. Later on, structured program- 
ming techniques for rv-systems and a kernel programming language AGAPIA 
have been introduced, with a particular emphasis on developing a structural 
spatial programming discipline, see [9, 10]. 

Structured process interaction greatly simplifies the construction and the 
analysis of interactive programs. For instance, method invocation in current 
00-programming techniques may produce unstructured interaction patterns, 
with free goto's from a process to another and should be avoided. Compared 
with other interaction or coordination calculi (e.g., 7r-calculus [20], actor models 
[1], REO [2], Ore [21], etc.), the rv-systems approach paves the way towards a 
name-free calculus and facilitates the development of modular reasoning with 
good expectations for proof scalability to systems with thousands of processes. 
A new and key element of our structured interaction model is the extension of 
temporal data types used on interaction interfaces. These new temporal data 
types (including voices as a time-dual version of registers) may be implemented 
on top of streams similar to the implementation of usual data types on top of 
Turing tapes. 

AGAPIA [9,22] is a kernel high-level massively parallel programming lan- 
guage for interactive computation. It can be seen as a coordination language on 
top of imperative or functional programming languages as C-l — h, Java, Scheme, 
etc. Typical AGAPIA programs describe open processes located at various sites 
and having their temporal windows of adequate reaction to the environment. The 
language naturally supports process migration, structured interaction, and de- 
ployment of components on heterogeneous machines. Nonetheless, the language 
has simple denotational and operational semantics based on scenarios (scenar- 
ios are two-dimensional running patterns; they can be seen as the closure with 
respect to the space-time duality transformation of the running paths used to 
define operational semantics of sequential programs). 

The backbone of our approach to interactive systems is the emphasized space- 
time duality principle: not only the model of (structured) rv-systems, but also 
most of its features or extensions developed so far are all space-time invariant. 
For the verification tasks, this duality is again our guiding light towards the de- 
velopment of Hoare-like spatio-temporal logics for structured rv-programs. We 
present a rich set of sound rules STHlogo for verifying structured rv-programs 
(no claim on their completeness is included). As a case study, we present an 

^ The term "interactive computation" often refers to interactive systems where one 
participant is human, dealing with development of powerful human-computer inter- 
faces. In our approach, all "participants" are "computing components". 



A HoARE Logics for Structured RV-Programs 3 

implementation and a detailed formal verification in STHlogo of a popular dis- 
tributed termination detection protocol. The method may be applied to many 
other sophisticated distributed protocols. A short description of the method fol- 
lows. 

For verification of sequential programs we have to find assertions in a few 
key points of the tested program and to prove certain invariance conditions, 
see, e.g., [16]. For rv-programs cut-points become contours, surrounding finite 
scenarios. The verification procedure [27] consists of the following three steps: 
(i) find an appropriate set of contours and assertions; (ii) fill in the contours 
with all possible scenarios; and (iii) prove these scenarios respect the border 
assertions. Except for the guess of assertions, the proof is finite and can be fully 
automatized. 

The verification of structured rv-programs follows the same pattern. However, 
structured rv-programs have a more restricted way to construct scenarios, hence 
the procedure is more regular: (1) provide assertions for each basic statement 
and (2) lift assertions to larger and larger programs applying STHlogo inference 
rules. 

The paper is organized as follows. We start with a brief presentation of 
scenarios and spatio-temporal specifications. Next, structured rv-programs and 
a scenario-based operational semantics are presented. A short section describes 
the syntax of AGAPIA vO.l language. Then, our approach for developing Hoarc- 
like spatio-temporal verification logics is presented. Finally, a detailed proof of 
the correctness of a termination detection protocol is included. A brief section 
on related works conclude the paper. 

2 Scenarios 

In this section temporal data, spatio-temporal specifications, grids, scenarios, 
and operations on scenarios are briefly presented. 

Spatio-temporal specifications. What we call "spatial data" are just the usual 
data occurring in imperative programming. For them, common data structures 
and the usual memory representation may be used. On the other hand, "temporal 
data" is a name we use for a new kind of (high-level) temporal data implemented 
on streams. A stream [3] is a sequence of data ordered in time, denoted as 
ao^ai^ . . . where cq, ai, . . . are its elements at time clocks 0, 1, . . ., respectively. 
Typically, a stream results by observing data transmitted along a channel: it 
exhibits a datum (corresponding to the channel type) at each clock cycle. 

A voice is defined as the time-dual of a register: It is is a temporal data struc- 
ture that holds a natural number. It can be used ("heard") at various locations. 
At each location it displays a particular value. 

This formulation may be difficult to understand at a first sight (the reader 
is invited to come back here after the reading of the section on rv-programs and 
their scenario semantics). In a different formulation, this means high-level tem- 
poral data structures on streams (including voices) may be common to multiple 
processes, each process having particular values for these data structures. 
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Voices may be implemented on top of a stream in a similar way registers 
are implemented on top of a Turing tape, for instance specifying their starting 
time and their length. Most of usual data structures have natural temporal 
representations. Examples include timed booleans, timed integers, timed arrays 
of timed integers, etc. 

A spatio-temporal specification S : {m,p) — > (n, q) (using registers and voices 
only) is a relation S C (N™ x W) x (N" x W), where m (resp. p) is the number 
of input voices (resp. registers) and n (resp. q) is the number of output voices 
(resp. registers). The associated relation S is often functional, sometimes written 
as {v \r) {v' I r'), where v,v' (resp. r, r') are tuples of voices (resp. registers). 

Specifications may be composed horizontally and vertically, as long as their 
types agree; e.g., for two specifications S'l : (rni,pi) {ni,qi) and 5*2 : (to2,P2) - 
(""■2,92) the horizontal composition Si > S2 is defined only if ni = m2 and the 
type of Si > 5*2 is (mi,pi + P2) ^ ("-2, 91 + 12)] the result is as expected: 
it consists in tuples ((i;, (ri, r2)), (w", (r'j^, r2))) such that there exists v' with 
((t;,ri),(«',r'i,)) e/i and ((«', ra), («", r^)) £ /2. 



Grids and scenarios. A grid is a rectangular two-dimensional array containing 
letters in a given alphabet. A grid example is presented in Fig. 1(a). Our default 
interpretation is that columns correspond to processes, the top-to-bottom order 
describing their progress in time. The left-to-right order corresponds to process 
interaction in a nonhlocking message passing discipline: a process sends a message 
to the right, then it resumes its execution. 

A scenario^ is a grid enriched with data around each letter. The data may 
be given in an abstract form as in Fig. 1(b), or in a more detailed form as in 
Fig. 1(c). 



aabbabb 
abbcdbb 
bbabbca 
ccccaaa 



(a) 



111 
AaBbBbB 

2 11 
AcAaBbB 

2 2 1 
AcAcAaB 

2 2 2 



(b) 




Fig. 1. A grid (a), an abstract scenario (b), and a concrete scenario (c 



The type of a scenario interface is represented as ti; ^2; ■ ■ • ; ife, where each 
tk is a tuple of simple types used at the borders of scenario cells. ^ The empty 
tuple is also written or nil and can be freely inserted to or omitted form such 
descriptions. The type of a scenario is specified as / : — * (e|s), where 

^ See [15] for less shape-constrained scenarios. 

^ If only registers and voices are used, then each tuple may by simply replace by a 
number (counting of its components). 
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w, n, e, s are the types for its west, north, east, south interfaces. For example, 
the type of the scenario in Fig. 1(c) is {nil; nil\sn; nil; nil) — > {nil; nil\sn; sn; sn), 
where sn denotes a spatial integer type. 

Operations with scenarios. We say two scenario interfaces t = ti;t2; ■ ■ ■ ;tk and 
t' = t'l; t'2; ■ ■ ■ ; t'f,, are equal, written t = t' , if k = k' and the types and the values 
of each pair ti,t^ are equal. Two interfaces are equal up to the insertion of nil 
elements, written t ~n t' , if they become equal by appropriate insertions of nil 
elements. 

Let Idm.p '■ {tti\p) {'m\p) denote the constant cells whose temporal and 
spatial outputs are the same with their temporal and spatial inputs, respectively; 
an example is the center cell in Fig. 2(c), namely /di,2- 

Horizontal composition: Let fi : {wi\ni) — > (e,;|si),z = 1,2 be two scenarios. 
Their horizontal composition /ii>/2 is defined only if ei =„ 1112 ■ For each inserted 
nil element in an interface (to make the interfaces ei and 'W2 equal), a dummy 
row is inserted in the corresponding scenario, resulting a scenario fi- The result 
/i > /2 is obtained putting /i on left of /2. The operation is briefly illustrated 
Fig. 2(b) and in more details in Fig. 3. The result is unique up to insertion or 
deletion of dummy rows. Its identities are Idm,Oi 1^ ^ 0- 

Vertical composition: The definition of vertical composition /i-/2 (see Fig. 2(a)) 
is similar, but now si =n n2- For each inserted nil clement (to make Si equal 
to 712), a dummy column is inserted in the corresponding scenario, resulting a 
scenario fi. The result /i • /2 is obtained putting /i on top of /2. Its identities 
are /do,m, m > 0. 

Diagonal composition: This is a derived operation. The diagonal composition 
fi • /2 (see Fig. 2(c)) is defined only if ei =„ W2 and si =„ 712- The result is 
defined by the formula 

/i • /2 - (/i > Ri> A) ■ {S2> Id> R2) ■ {A> Si> f2). 

for appropriate constants R, S, Id, A. Its identities are /c?„j „,m,n > 0. (The 
involved constants R, S, Id, A are described below.) 

Constants: Except for the defined identities, we use a few more constants. 
Most of them may be found in Fig. 2(c): a recorder R (2nd cell in the 1st row), 
a speaker S (1st cell in the 2nd row), an empty cell A (3rd cell in the 1st row). 
Other constants of interest are: transformed recorders Fig. 2(e) and transformed 
speakers Fig. 2(g). 



X 



X 



(a) 



(=)□ 



(b) 



Fig. 2. Operations on scenarios 
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Fig. 3. Details for the horizontal composition of scenarios 



3 Structured rv-programs 

Rv-programs [26] resemble flowcharts and assembly languages: one can freely 
uses go-to statements with both, temporal labels (free jumps in a process from 
a statement to another) and spatial labels (free jumps in a macro-step from 
a process to another). The original approach of the authors in 2006 was to 
introduce structured programming techniques on top of rv-programs. However, 
the resulted structured rv-programs and their scenario based semantics may be 
described directly, from scratch. The lower level of rv-programs is still useful (and 
important!), as it may be used as a target language for compiling and is more 
appropriate for running programs on (possible multicore/manycore) computer 
architectures. Below, we restrict ourself to structured rv-programs. The Hoare 
logics for structured rv-programs, to be presented later in the paper, has its 
roots in a Floyd logics developed for unstructured rv-programs [27]. 

The syntax of structured rv-programs. The basic blocks for constructing struc- 
tured rv-programs are modules. A module gets input data from its west and 
north interfaces, process them (applying the module's code), and delivers the 
computed outputs at its east and south interfaces. While one can argue for the 
use of nondetcrministic behaviors for processes associated to modules, we afraid 
of doing so: in all the example we have developed so far the basis modules (and 
the resulting structured rv-programs) have deterministic behavior. Nondetcr- 
ministic behaviors naturally occur at more abstract levels when lot of details on 
particular low-level temporal or spatial data are hidden. 

On top of modules, structured rv-programs are built up using "if" and both, 
composition and iterated composition statements for the vertical, the horizontal, 
and the diagonal directions. The composition statements capture at the program 
level the corresponding operations on scenarios. The iteration statements are also 
called the temporal, the spatial, and the spatio-temporal while statements - their 
scenario meaning is described below. 

The syntax for structured rv-programs is given by the following BNF grammar 



P y.^X \ if{C)then{P}else{P}\ P%P \ P#P \ P%P 

I whileJt{C){P} I while.s{C){P}\ while.st{C){P} 
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X ::= module{listen t_vars}{read s.vars} 
{code; }{speak t_vars}{write sjuars} 

This is a core definition of structured rv-programs, as no data types or language 
for module's code is specified. On the other hand, Agapia, to be shortly pre- 
sented, is a concrete incarnation of structured rv-programs into a fully running 
environment. 

Notice that we use a different notation for the composition operators on 
scenarios ■,>, • and on programs %,#,$. Moreover, to avoid confusion, the ex- 
tension of the usual program composition operator ';' to structured rv-programs 
(i.e., the vertical composition) is denoted by a different symbol "%". 

Operational semantics. The operational semantics 

I I : Structured rv-programs Scenarios 

associates to each program the set of its running scenarios. 

The type of a program P is denoted P : {w{P)\n{P)) — > (e(P)|s(P)), where 
w{P)/n{P)/e{P)/s{P) indicate its types at the west /north/east/south borders. 
On each border, the type may be quite complex (see AGAPIA interface types in 
Sec. 4). The convention is to separate by "," the data from within a module and 
by ";" the data coming from different modules. This convention refers to both 
spatial and temporal data. 

The type associated to a program may include different types for the in- 
terfaces of its running scenarios. For instance, a temporal while statement may 
have running scenarios with different numbers of rows which may exhibit differ- 
ent interfaces at their west/east borders. With this explanation, the definition 
below makes sense. We say, two interface types match if they have a nonempty 
intersection. 

Modules. Modules are the starting blocks for building structured rv-programs. 
The listen (read) instruction is used to get the temporal (spatial) input and 
the speak (write) instruction to return the temporal (spatial) output. The 
code consists in simple instructions as in the C code. No distinction between 
temporal and spatial variables is made within a module. 

A scenario for a module consists of a unique cell, with concrete data on 
the borders, and such that the output data are obtained from the input data 
applying the module's code. 

Composition. Programs may be composed "horizontally" and "vertically" as 
long as their types on the connecting interfaces agree. They can also be composed 
"diagonally" by mixing the horizontal and vertical compositions. 

For two programs Pi : {wi\ni) — > (ei\si), z = 1,2 we define the following 
composition operators. 

Horizontal composition: Pi#P2 is defined if the interfaces ei and W2 match, 
see Fig. 4(left). The type of the composite is (wi|ni; (e2|si; S2). A scenario 

for Pi#P2 is a horizontal composition of a scenario in Pi and a scenario in P2. 
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Fig. 4. Vertical/horizontal compositions and "if" statement 



Vertical composition: Pi%P2 is similar. 

Diagonal composition: Pi$P2 is defined if ei matches W2 and Si matches 
712- The type of the composite is — > (e2|s2}- A scenario for Pi$P2 is a 
diagonal composition of a scenario in Pi and a scenario in P2. 

If. For two programs Pi : {wi\ni) (e,;|si}, i = 1,2, a new program Q = 
if (C) then Pi else P2 is constructed, where C is a condition involving both, the 
temporal variables in wiri'W2 and the spatial variables in ninn2, see Fig. 4(right). 
The type of the result is Q : {wi U 'W2\ni U ^2) (ei U e2|si U 52}- 

A scenario for Q is a scenario of Pi when the data on the west and the north 
borders of the scenario satisfy condition C, otherwise is a scenario of P2 (with 
these data on the borders). 

While. Three types of while statements are used for defining structured rv- 
programs, each being the iteration of a corresponding composition operation. 

Tempora/ u;/iile.' For a program P : {w\n) — > (e|s), the statement w/iiZeJ (C){P} 
is defined if the interfaces n and s match and C is a condition on the spatial 
variables in n n s. The type of the result is {{w; )*\n U s) — > ((e; )*\n U s). A 
scenario for while J {C){P} is either an identity, or a repeated vertical compo- 
sition /i ■ /2 • ■ • ■ • /fc of scenarios for P such that: (1) the north border of each 
fi satisfies C and (2) the south border of fk does not satisfy C. 

Spatial while: whiles (C){P} is similar. 

Spatio-temporal while: For P : {w\n) — > (e|s), the statement whilest (C){P} 
is defined if w matches e and n matches s and, moreover, C is a condition on 
the temporal variables in iwHe and the spatial variables in nHs. The type of the 
result is {w U e\n U s) — > (w U e|n U s). A scenario for whilest (C){P} is either 
an identity, or a repeated diagonal composition /i • /2 • • ■ • • /fe of scenarios for 
P such that: (1) the west and north border of each fi satisfies C and (2) the 
east and south border of fk does not satisfy C. 

A few particular cases of while statement may be easier to understand and 
use. For instance, when the body program P of a temporal while statement has 
dummy temporal interfaces, the temporal while coincides with the while from 
imperative programming languages. 



A HoARE Logics for Structured RV-Programs 



9 



E :■- n \ V \ E + E \ E * E \ E - E \ E/E 
B -.--blV \ BL&lB I B\\B \ \B\E <E 

Programs 

W ::= nil \ new x : SST \ new x : STT 
\x~E\ if{B){W}else{W} 
I W; W I while{B){W} 
M :■- module{listen x : STT}{read x : SST} 
{W; }{speak x : STT}{write x : SST} 

P :■- nil I M I if{B){P}else{P} 
P%P I P#P I P$P 
1 while.t{B){P} I while^{B){P} 
I while.st{B){P} 

Fig. 5. The syntax of AGAPIA vO.l programs 

4 The AGAPIA vO.l programming language 

To develop and verify structured rv-programs for concrete computation tasks 
we need at least a couple of basic data types. The AGAPIA vO.l programming 
language [9], to be be shortly introduced, forms a minimal languages: it describes 
what is obtained allowing for spatial and temporal integer and boolean types and 
applying structured rv-programming statements. 

The syntax for AGAPIA vO.l programs is presented in Fig. 5. The vO.l 
version is intentionally kept simple to illustrate the key features of the approach 
(see [22] for vO.2 extension, including high-level structured rv-programs). The 
language is space-time invariant'' and has global scoping within modules and 
local scoping outside. 

The types for spatial interfaces are built up starting with integer and boolean 
sn, sb types, applying the rules for U, (_)* to get process interfaces, then the 
rules for U, (_; )* to get system interfaces. The temporal types are similarly 
introduced. Given a type V, the notations V{k), V.k, V.[k], V@k, V@[k] are used 
to access its components.^ Expressions, usual while programs, modules, and 
programs are then naturally introduced. Notice that AGAPIA vO.l has a strongly 
restricted format: module and program statements are not mixed (in the new vO.2 
version of AGAPIA [22] programs have no longer this restriction - modules and 
programs can be freely combined). 

An useful derived statement, to be used in the next sections, is a spa- 
tial "for" statement f or_s (i=a; i<b; i++) {R}. This is a macro stating for i=a# 
while_s (i<b) {R# where i=a and i++ denote modules with such code, 

with empty spatial interfaces, and whose temporal interfaces are equal to the 
temporal interface of R (where i is included) . 

* This means, we can formally define a space-time duality operator which maps an 
AGAPIA vO.l program P to another AGAPIA vO.l program such that P = P^^. 
^ See [9] for details - we will not use this notation in the present paper. 



Interfaces 

SST :■- nil \ sn\sb\ {SST U SST) 
I {SST, SST) I {SST)* 

ST::= {SST) \ {ST U ST) 
I {ST- ST) I {ST;)* 

STT :■- nil \ tn \ tb \ {STT U STT) 
{STT, STT) I {STT)* 

TT :■- {STT) I {TTUTT) 
I {TT;TT) I {TT;)* 

Expressions 

V :■- x: ST \ x:TT \ V{k) 

I V.k I V.[k] I V@k I V@[k] 
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5 Towards a Hoare-like logic for structured rv-programs 

This section describes an approach for developing verification logics for struc- 
tured rv-programs. The presentation starts with a fcw words on the verification 
of unstructured rv-programs (more details on developing Floyd logics for un- 
structured rv-programs may be found in [27]). 

The semantics of (structured) rv-programs uses scenarios, a two-dimensional 
version of running paths used in sequential programs. The lifting of Floyd veri- 
fication method to rv-programs is essentially a two-dimensional extension where 
cut-points with assertions become contours (borders of certain scenarios) with 
appropriate assertions. 

The method. The Floyd method for unstructured sequential programs, requires 
to find assertions in a fcw key points of the programs and to prove appropriate 
invariance conditions. It should be at least one cut-point along each loop. The 
set of cut-points ensures that: (1) each syntactically possible path from input to 
output is decomposed into a sequence of small paths piP2 ■ ■ - Pk, each pi tarting 
and ending with cut-points and containing no cut-point inside and (2) the set of 
all these pi forms a finite set K. The proof finally reduces to the verification of 
the invariance conditions for the paths in K. 

For rv-programs, cut-points becomes contours surrounding finite scenarios. 
Their set must be finite. The condition to "break all loops" becomes "each 
syntactically possible scenario can be decomposed in pieces corresponding to 
these contours" . To conclude, the verification procedure for rv-programs consists 
of the following three steps: (i) find an appropriate set of contours and assertions; 
(ii) fill in the contours with all possible scenarios; and (iii) prove these scenarios 
respect the border assertions. Notice that, except for the guess of good assertions, 
the proof is finite and can be fully automatized. 

Structured rv-programs have a more restricted way to construct scenarios, 
hence the procedure is expected to be more regular: (1) provide assertions for 
each basic statement and (2) use appropriate inference rules to lift the assertions 
to larger programs. 

H oar e- assertions. As we said, structured rv-programs have a restricted way to 
form scenarios, hence one expects the assertion format may be somehow sim- 
plified. However, notice that we are working in an open environment, hence the 
local application of a rule is to be integrated into a larger context, including as- 
sertions on parts of the contour that may look irrelevant to the current piece of 
code^, but are needed to infer the correctness of the behavior of the full system. 

An assertion (for structured rv-programs) is defined using a rectangular con- 
tour surrounding a piece of structured rv-program and extended with dummy 
contours from its top-right and bottom-left corners, loosely along the 2nd diag- 
onal. (Contours and assertions, to be shortly defined, are illustrated in Fig. 6.) 



® An example is P2, the invariant used in the verification of the termination detection 
protocol in the next section. 
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Formally, a H oar e- assertion contour is defined by a pair of lines starting from 

the same point , , , , 

TN''E^a,TE^N''a 

where N and E denote unit lines towards the north and the east directions, 
and T and a are sequences of lines of the following types: N°-^E^^ . . . N°'''E^'', 
E^^ . . . N'"' E^'' , N''^ E^^ . . . N"'\ E^^ . . . N''^ where all a^,bj>l. Assertions use 
variables on the contour border. A border unit line is either horizontal and has 
an index from left, or vertical and has an index from top/ The variables for the 
unit border lines are refereed to using these indices. 
A Hoare assertion (see Fig. 6(left)) is a formula 
{T{N''E^)a:C} P {t{E^ N'')a:C'} 
where C is a condition on the west-north part T{N^E^)a of the contour, P is a 
structured rv-program, and C" is a condition on the south-east part T{E^N'')a 
of the contour. The conditions C, C" arc first-order formulas described using 
contour variables. The pair of parentheses (..) locates the part of the contour 
where program P is used. 













sigma/ 









Fig. 6. Illustrations for the "Basic Rule" and the "Rule for horizontal composition" 



Inference rules. We consider the following set of proof rules for structured rv- 
programs: 

Basic rule (see Fig. 6(left)): The validity of an assertion {T{NE)a:C} M {T{EN)a:C'} 
for a module M is reduced to the validity of the assertion {C} M {C} in the setting 
of usual while programs (enriched with equalities showing that the variables in r 
and (J does not change by passing form C to C'). 

Rule for horizontal composition (see Fig. 6(right)): If 
{r(iV'= cr:C} PI {t{E^ N'')E'^ g:C1} and 

{tE\N''E"')(j:C1} P2 {tE^E"" N'')(j:C2}, then 
{r(iV'=£;'+™)cr:C} P1#P2 {r (P'+'"iV''')a:C2}. 

Notice that the index is not changed when a program is applied. However, it may 
be changed when one insert or delete lines with nil type on the appropriate borders 
to handle program compositions. 
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Rule for vertical composition: similar 
Rule for diagonal composition: If 

{T(N''E')a:C} PI {T{E^N'')a:Cl} and 

{T{N''E')a:Cl} P2 {t{E^ N'')a:C2}, then 

{T(N''E')a:C} P1$P2 {t{E' N'')a:C2}. 

(Notice that CI is used on two different contour lines. The above convention on 

variable indices ensures the rule is sound.) 
Rule for "if": For Q = if(Cond){Pl}else{P2}, if 

{r{N''E')a:C ACond} PI {t{E^ N'')a:C'} and 

{T{N''E')a:C A^Cond} P2 {t{E' N'')a:C'}, then 

{T{N''E')a:C} Q {t{E' N'')a:C'}. 
Rule for autonomous temporal or spatial "while": For a temporal while with dummy 

temporal interfaces (i.e., the west and east interfaces have a nil type), the classical 

while rule may be used. By space-time duality, a similar rule applies to a spatial 

while with dummy spatial interfaces. 
Rule for spatio-temporal "while": If an invariant Inv may be found such that 

{r(iV*£;')cr:7nw A Cond} P {t{E'^ N'')a:C'} and C" ^ Inv, then, 

{r{N'' E'^)a:Inv} ■while_st{Cond){P} {t{E^ N^)a:Inv A ^Cond}. 

(See the comment on the diagonal composition to clarify the use of the assertions 

C and Inv on different contour lines.) 
Rule for a simple "for": If i is not changed by R in a statement Q — f or_s (i=0 ; i<a; i++) {R}, 

then the following rule applies; if 

{r{E'y{N''E'){E')''-'-'-a:C,} R {r(£;')^(S'iV'=)(S')'"--'~ V:Cj+i}, 
for all j < a, then 

{T{N\E'r~^)a:Co} Q {t{{E'Y-^ N^y-.Ca-i} ■ 
Rule for implication: For a Hoare assertion {r{N*' E^)cr:C} P {t{E' N'')a:C'}, if D ^ 
C, C" ^ D', then {T{N''E')a:D} P {t{E^ N^)a:D'}. 

Theorem 1. The inference rules are sound, i.e., if an assertion 

{t{N''E^)(j:C} P {T{E^N^)a:C'} 

is proved, then all scenarios of P satisfying the input condition satisfy the output 
condition, too. □ 

6 A case study: The verification of a distributed 
termination detection protocol 

As a case study, wc verify the correctness of a termination detection protocol. 
The activity of processes and their interactions are all described using structured 
rv-programs. 

Termination detection is quite a popular research topic in distributed sys- 
tems. The aim is to find when a set of distributed processes have terminated. 
The problem is particularly complicate as one has to combine a local termina- 
tion condition (each process has finished its current jobs) with a global condition 
(no messages are in transit, as such messages may reactivate already terminated 
processes). There are many termination detection protocols - we study a popular 
(dual-pass) ring termination detection protocol (see, e.g., [8]). 



A HoARE Logics for Structured RV-Programs 13 

Ring termination detection. The dual-pass ring termination detection protocol 
is used to detect the termination of a pool of distributed processes logically 
organized as a ring. The protocol can handle the case when processes may be 
reactivated after their local termination. To this end, it uses colored (i.e., black or 
white) tokens. Processes are also colored: a black color means global termination 
may have not occurred. The algorithm works as follows: 

(1) The root process Pq becomes white when it has terminated and it gener- 
ates a white token that is passed to Pi . 

(2) The token is passed through the ring from one process Pi to the next when 
Pi has terminated. However, the color of the token may changed. If a process 
Pi passes a task to a process Pj with j < i, then it becomes a black process; 
otherwise it is a white process. A black process will pass on a black token, while 
a white process will pass on the token in its original color. After Pi has passed 
on a token, it becomes a white process. 

(3) When Pq receives a black token, it passes on a white token; if it receives 
a white token, all processes have terminated. 



6.1 Implementation 

Suppose there are n processes, denoted 0, . . . ,n-l. Besides the input n, the pro- 
gram uses the spatial variables id : sint, c : {white, black}, active : sBool 
and the temporal variables tn, tid:tlnt, msg : tIntSet[ ]. Their role is de- 
scribed below. 



A run (for termination detection program) 



II 



Pk 



PI 
Y 

P2 



P3 



Fig. 7. Vertical and horizontal compositions and "if" statements 



Our structured rv-program P implementing the dual-pass ring termination 
protocol is the diagonal composition of an initialization program I and a core 
program Q, 

P I $ Q 

where 



I = Il# f or_s(tid=0;tid<tn;tid++){l2}# 
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II — module{listen iiil}{read n}{ 

tn=n; token. col=black; token. pos=0; 
}{speak tn,tid,msg[ ] , token(col ,pos) }{write nil} 
12= module{listen tn,tid,msg[ ] , token(col ,pos) }{read nil}{ 
id=tid; c=white; active=true; msg[id] =null ; 
}{speak tn,tid,msg[ ] , token(col ,pos) ; }{write id, c, active} 
Q= while_st (! (token. col==white kk token. pos==0) ) { 

f or_s (t id=0 ; t id<tn ; tid++) {R}} 
R= modulejlisten tn,tid,msg[ ] ,token(col,pos)}{read id, c , active}} 
for(j=0; j<tn; j++)} //take my jobs 
if(msg[j] contains id)} 
msg[j]=msg [j]-{id}; 
active=true ; } ; } 
if (active)} //execute code, send jobs, update color 
delay (random_time) ; 
r=random(tn-l) ; 

f or (i=0; i<r ; i++) } k=random(tn-l) ; 

if (k ! =id) }msg [id] =msg [id] U}k}} ; 

if (k<id)}c=black};} 
active=random(true , false) ;} 
if(!active kk token. pos==id)} //termination 
if (id==0) token. col=white ; 
if(id!=0 kk c==black)} 

token . col=black ; c=white} ; 
token. pos=token.pos+l [mod tn] ; } 
}}speak tn,tid,msg[ ] ,token(col,pos) ; }}write id, c, active} 

Notice that, except for the operations on sets (for which AG API A programs 
have to be provided), the code represent a vahd AG APIA vO.l program. 

Comments. The spatial variables id, c, active represent the process identity, its 
color, and its active/passive status. The temporal variables used in this program 
are: (i) tn, tid - temporal versions of n, id; (ii) msg[ ] - an array of sets, where 
msg[k] contains the id of the destination processes for the pending messages 
sent by process k; (iii) token. col - an element of }white, black} representing 
the color of the token; and (iv) token. pos - the number of the process that has 
the token. 

The program starts with the initialization of the network (program I) by acti- 
vating all the processes (and setting the fields id, c, active). Initially, nisg[i] = 0, 
for all < i < n, because no jobs were sent and the default color/position of the 
token is black/0. 

After the initialization part and until the first process receives a white token 
back, each process executes its code. If one process has the token and terminates, 
it passes the token to the next process (only the first process has the right to 
change the color of the token into white once it terminates) . 

When a process executes the code R, whether active or passive, it checks if 
new jobs were assigned to it; if the answer is positive, it collects its jobs from 
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the jobs lists and stays/becomes active. When it is active, it executes some code, 
sends new jobs to other processes, and randomly goes to an active or passive 
state. If it has the token, it keeps it until it reaches termination and afterward 
it passes it. A white process will pass the token with the same color as it was 
received and a black process will pass a black token (after passing the token, the 
process becomes white). 

6.2 Verification 

The program P is the diagonal composition of the initialization block and the 
repeated diagonal compositions given by the while_st statement. A typical run 
is presented in Fig. 7. In each case, the temporal/spatial output of a block 
becomes the temporal/spatial input of the next block. 

For I, the input is a spatial variable n. The output satisfies the condition: 

Vfc G [0,7i) : [id, c, active) [k] = (k, white, true) 

Atn = n A token = (black, 0) A Vfc G [0, n) : msg[k] = 0. 

Notice that the spatial interface is expanded on n processes 0, 1, ... ,n — 1. The 
notation (id, c, active) [k] refers to the the values of variables (id, c, active) in 
process k. 

The invariant Inv. For Q we need to find appropriate invariant properties. 
We define the following properties and prove they are satisfied by the program 
f or_s (tid=0 ; tid<tn; tid++) {R}: 

PI: token = [white, i) 

[(Vr G [0, i — 1] : active[r] ~ false A msg[r] ~ 0) 
V (3fc > i - 1 : c[k] = black)] 
where the value i — 1 is interpreted as <n — 1 for i = 0. 

In words, if the token is white and reached process i, then all processes with 
smaller id terminate and have no pending messages sent^ or a process with a 
larger id is black. 

P2 token. col = white — s- (Vfc G [0,n) : msg[k] 7^ — > c[fc] = black) 

In words, if a process has a job inserted in its pending message list, then its color 
is black. 

We want to prove Inv = PI A P2 is really an invariant, i.e., the same assertion 
Inv, translated to the output values of the variables, holds at the end of the f or_s 
statement. Formally, 

{|/nu|}f or_s(tid=0;tid<tn;tid++){R}{|/nw|}. 

Notice that due to the fact that the token is black, Inv holds at the beginning 
of the spatio-temporal while. 

* The pending message lists are the lists of messages that have been inserted in and 
not removed from the message lists during a complete passing through the ring. 
Formally, they are msg[r]'s at the start of the for_s statement. 
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Proof of the invariance of Inv. To simplify the presentation, wc directly prove 
the invariance of Inv for f or_s (tid=0 ; tid<tn; tid++) {R}. A fully formal proof, 
including an appropriate new invariant for R itself, in included in Appendix A. 

Suppose Inv holds at the start of the for_s statement. We want to prove 
that the property Inv' = Pi' A P2', where Inv' is Inv translated to the output 
values of the variables^, holds at the end of the f or_s statement. 

First, we prove Pi', where 

PI' : token' = {white, i') 

[(Vr e [0, z' - 1] : active'[r] = false A msg'[r] = 0) 
V(3fc>i'-1: c'[fc] = black)] 

Suppose token' .col = white; then token. col = white, too. Notice that Vr S 
[i,i' — 1] : active'[r] = false A msg'[r] = holds because: (i) the token could 
not reach the process i' unless processes i, . . . , i' — 1 hadn't terminated and (2) 
token' .col hadn't been white unless msg'[i], . . . , msg'[i' — 1] are all empty. 

As PI holds and token = {white, i), either (i) or (ii) below applies, where: 

(i) Vr G [0,2 — 1] : active[r] = false A msg[r] = 0: In this case: 

(a) If all processes 0, . . . ,i — 1 stay passive, then by the above observation this 
situation is extended to Vr £ [0, z' — 1] : active' [r] = false A msg'[r] = and we 
are done. 

(b) If one process 0, . . . ,i — 1 becomes active, it may be reactivated only by a 
message from a process k with k > i — I (indeed, msg[0\, . . . , msg[i — 1] are all 
empty). Then, by P2, c[k] — black. Moreover fc > i' — 1 (otherwise token' .col 
hadn't been white), hence c'[k] = black and the second part is true. 

(ii) 3k > i — 1: c[k] = black: In this case, k > i' — 1 (otherwise token'. col 
hadn't been white) and c'[k] = black, hence the implication holds. 

Next, we prove P2', where 

P2' : token'. col = white ^ (Vfc G [0, n) : msg'[k] ^ 9 ^ c'[k] = black) 

Notice that after the execution of R by the process k, msg'[k] consists in the 
processes that were contacted by k. The execution of R for tid = k is followed 
by the execution of R for k < tid < tn. All these executions of R that follows, 
will discard all the messages sent to processes greater than k from msg'[k] and 
consequently, by the end of the f or_s, msg'[k] C [0, k). 

Hence, if msg'[k] ^ 0, then the process k had sent a message to a process p 
with p < k and the color of the process became black. Moreover, if token' .col = 
white, then the color of the process stayed black until the end of the for_s 
instruction, which implies c'[fc] = black. 

The final step. Applying the rule for the spatio-temporal while 

{|/ni;|}while_st ( ! (token= (white ,0) )) {Q ' }{|/rti; A {token = {white, 0))\} 

^ We use the standard "prim" notation, i.e., if a; is a variable, then x' refers to the 
value of the variable x at the end of the program. Here, the convention applies also to 
i (which is not directly a variable of the program, but it actually denotes token.pos). 
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where Q' = for_(tid=0;tid<tn;tid++){R}, it follows that 

Vi G [0, tn — I]: active[i\ = false A msg[i] = 

hence all process have terminated and there are no pending jobs/messages in 
the communication lists. 

Theorem 2. The program for the dual-pass ring termination detection protocol 
is correct. □ 

It would be interesting to compare our proof with proofs of the protocol using 
process algebra or other formal verification methods, if such proofs are available. 

7 Related and future works 

This is a brief section on related works, with emphasis on two-dimensional pat- 
terns and spatio-temporal logics. Our grids (scenarios without data around) are 
closely related to two-dimensional (or picture) languages [12,17]^" - actually, 
finite interactive systems [25] (on which rv-systems are based), are equivalent to 
tile systems or to existential monadic second order logic [13]. Regarding scenar- 
ios, a worthwhile approach may be to use results on two-dimensional languages 
in combination with model-checking to (lightly) verify rv-programs. 

Space and time are fundamental entities, so no surprise to find many pro- 
posals on developing space-time logics. Compared with [6], we use linear not 
branching space and time. Tile logic [4, 11] use similar two-dimensional patterns, 
but with emphasis on rewriting and declarative computation models. Other in- 
teresting space-time proposals on verifying mobile or open systems are presented 
in [19,28]. 
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Appendix A: On the termination detection protocol 

A fully formal proof of Inv invariance. Here we give a fully formal proof (in 
STHlogo for 

{ I Inv I }f or_s ( t id=0 ; t id<tn ; t id++ ) {R}{ | Inv \ } 

For the beginning, we identify a few more detailed assertions, which essentially 
depend on tid and describe the effect of the computation within R: 

Ql : (case token. col = white A tid < token.pos) 
token' = token A V/c 7^ tid : msg'[k] = msg[k] — {tid} A 
[ {active[tid] = false A ^k, tid £ msg[k] 

— > active' [tid] = false A msg'[tid] = 0) 

V {active[tid] = true V 3k, tid G msg[k] 

msg'[tid] C [0, tid) U [tid + 1, n) A 
msg'[tid] n [0,tid) 7^ ^ c'[tid] = black)] 

Q2 : (case token. col = white A tid — token.pos) 
yk ^ tid: msg'[k] = msg[k] — {tid} A 
[ [active' [tid] = true 

—^ token' = token A 

msg'[tid] n [0,tid) 7^ ^ c'[tid] = black) 

V [active' [tid] — false 

token' .pos = token.pos + 1 A 

token' .col — white msg'[tid] D [0,tid) — 0)] 

Q3 : (case token. col — white A tid > token.pos) - same as Ql. 

To prove Inv, we use a more detailed version Inv2 satisfying the following 
properties: (i) If Inv2 holds "up-to" to an tid and module R is applied, then 
Inv2 holds up to tid + 1; (ii) Inv follows from the fact that Inv2 holds for the 
last value of tid. Formally, we have to prove 

{[Inv2[} R {[Inv2'[}; 
Inv2 A [tid = n) Inv 

The basic step is illustrated in the next figure (Fig. 8). 



R 



Fig. 8. The basic step for the application of Hoare method: a classical triple surround- 
ing R extended with an empty contour 

The new invariant Inv2 is PldAP2d, where Pld,P2d are the following slightly 
more detailed variations of the previous properties PI ,P2: 
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Pld : token — {white, i) — > 

[(Vr g [0, i — 1] : active[r] — false A msg[r] C [max{tid, i), n)) 
V (3fc > z - 1 : c[k] = black)] 
where, as before, the vahie i — 1 is interpreted as tn — 1 for i = 0. 
P2d : token. col = white 

Vfc e [0, tid) : msg[k] C [0, k) U [tid, n) A 

msg[k] n [0, fc) ^ ^ c[k] = black 



Proof o/Pld. For {|Pld|} R {|Pld|}, we have to prove that Pld and Ql-3 impHes 

Pld' : token' = {white, i') 

[(Vr G [0, i' — 1] : active'[r\ ~ false A msg'[r\ C [TOaa;(iic?', i'), n)) 
V(3fc> i'-l: c'[fc] =6/acA:)] 

Suppose token' = {white, i') and i' = i, hence: tid 7^ i or {tid = i and process 
tid doesn't terminate). By Pld, either (i) or (ii) holds, where 

(i) 3fc > i — 1 : c[k] = black: The property is preserved, i.e., c'[k] = black. 
(Indeed, a black process may become white only if it terminates, which is 
not the case as i' = i.) 

(ii) Vr G [0,2 — 1]: active[r] = false A msg[r] C [max{tid,i),n) and -'{3k > 
i ~ 1: c[k] = black): For the "active" part: 

• If tid > i the property is outside of the action of R, hence still true. 

• Iftid <i, the process tid cannot be activated by a processes r with r <i 
(there are no messages for tid there). On the other hand, if a process r, 
with r > i, activates process tid, then by P2d its color c[r] is black and 
this contradicts this care premises. 

For the second part, notice that a process r with r 7^ tid has msg'[r] = 
msg[r]~{tid}, while the process tid with tid < i is inactive, hence msg'[tid] = 
0. 

Suppose token' = {white, i') and i' = i + 1, hence: tid = i, the process tid 
terminates, and tid was a white process before termination. Again by Pld, either 
(i) or (ii) holds, where 

(i) 3k > i — 1 : c[k] = black: As token' = {white, i'), actually k > i, hence the 
property is preserved. 

(ii) Vr e [0,i — 1]: active[r] = false A msg[r] C [max{tid,i),n) and -i{3k > 
i ~ 1: c[k] = black): For r < i the proof is as before. For r = i, by the 
previous observations, active'[i] = false A msg'[i] C [i + l,ri), hence the 
property is prcscrvcd^^. 

Finally, notice that at the end of the for_s statement tid = n; moreover, 
clearly Pld A {tid = n) ^ PI. 

Notice that tid = i, hence i + 1 — i' = tid' — max {tid' , i'). 
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Proof o/P2d. For {|P2d|} R {|P2d|}, we have to prove 

P2d' : token' .col = white —^ 

\fk G [0, tid') : msg'[k] C [0, k) U [tid', n) A 

msg'[k] n [0, k) ^ 9 ^ c' [k] = black 

This directly follows from P2d and Finally, after f or_s statement tid = n 

and P2d A {tid ^ n) ^ P2. 

Theorem 3. The program for the dual-pass ring termination detection protocol 
is correct. Moreover, there is a fully formal proof of its correctness using the 
STHlogo inference rule defined in Sec. 5. □ 



In the last implication, if msg'[k] D [0, fc) 7^ the process becomes blacli by the first 
part of the code of R. Its color may be changed to white by the last part of the code 
of R only if the process has the token and terminates, but then the token will be 
black and this contradicts the premise token' .col = white. 



